Computer processing 
of dates outside the 
twentieth century 




by B. G. Ohms 



The use of existing date ^J^P^ ^Sd? of is 
seated. 



The Gregorian calendar serves us quite well in 
L dSy-to-day living. Due to discontinuities in 
various divisions, however, it is _not r^drty 
adaptable to computer programming. ™™ * 
comes more apparent as we approach the new cen 
£5 FevTefficient, easy-to-use functions for mamp- 
Sng dates have been produced. Ag • tobe ««£ 
ered are the human requirements for ease ot use, 
development, and maintenance. Other ^dera- 
tions include storage costs, efficiency, and adapubil- 
ItfaclL many different applications and environ- 

mcnts. 

Some early deconversion P^ms were ^.ctjof 
expediency rather than planning, created tosoive 
3c problems rather than for general program- 
nSg use. Different functions were created at diflfer- 
SmS. Naming conventions, ^nvoc^on forma^ 
and implementation methods have otoljen^ 
consistent. Programs that provided a day-of-week 



function were rare. Also rare were programs for 
deriving a new date by adding or subtracting from 
another date in a different year. The funct.ons that 
were available were normally not part of an inte- 
grated system for providing compatibility with most 
oY me common date formats. Since documentauon 
was not always created or maintained indmduals 
were often unaware of what was available. Today, 
dating format standards are being discussed inter- 
nationally. The date-processing method presented in 
this paper is expected to be compatible with any 
folSe international standard date format _as 
well as with the several formats discussed in this 
paper. 

Typically, oaies are displayed and stored in the. J* 
Z J Gregorian formats. Concept jand fonttg 
of both Julian and Gregorian date formal ared^ 
cussed later in this paper. Simply sta ted; ^ J uton 
date is the number of the year together with the serial 
JSnta of the day of that year. ^0^. 
format consists of month, day of mont *J^S 
Mtoy calendars show Julian dates printed in small 

numerals. 

A format termed the Lilian date format is presented 
Cere™ the basis for making date conversions of the 

« Copyright 1 986^IntcnuUon^n«h^^o« t 
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of royally provided that ^^St copyright 
without alteration and (2) the Jo«W^o«^^ ^ 
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ftee without further perm^wnbv compu^^ olbef 
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type mentioned earlier. The Lilian format, which 
may be stored in three bytes of memory, provides 
the storage capacity for dates well beyond the year 
10 000. This format handles processing across cen- 
tury years and other aspects of date conversion not 
currently adaptable to computer programming. 
Practical date processing services must provide ease 
of use for the end user, developer, and maintainer. 
Such services must also eliminate date ambiguity, 
achieve excellent performance, and minimize stor- 
age. 

The two positions traditionally used in both Julian 
and Gregorian date formats implicitly represent a 
year within a century. However, this system is inad- 
equate for representing dates in more than one cen- 
tury. For example, it is ambiguous as to whether 03 
represents the year 1903 or the year 2003. The Lilian 
date format avoids the ambiguity by using seven 
positions for the number of days from the beginning 
of the Gregorian calendar. October 15. 1582. 

Origins of date complexity 

Julian calendar. The Julian calendar was established 
in 46 B.C. by Julius Caesar. 1 It replaced a system of 
constant adjustments, more for political reasons than 
for correcting inaccuracies in timekeeping. After a 
bad start, with the first few leap years being calculated 
incorrectly, it served quite adequately for many cen- 
turies. The Julian calendar is not the same as the 
Julian date, which was previously defined. The Ju- 
lian calendar was a time-measuring system, which 
we now discuss. 

The scheme of the Julian calendar was quite simple. 
The calendar year consisted of 365-day years, with 
years evenly divisible by four having 366 days. The 
resulting average year of 365.25 days was slightly 
longer than the tropical year, which is based on the 
time marked by the passage of equinoxes. That slight 
difference resulted in a gradual drift of the calendar 
year. The resulting difficulty in properly setting the 
date of celebration of Easter caused great concern to 
the Roman Church. The date for Easter is related to 
the date for Passover, which is related to the vernal 
equinox. By the sixteenth century, the discrepancy 
approximated ten days, and the desire for calendar 
reform intensified. An artifact of this discrepancy 
manifests itself today in the differences in dates for 
Christmas and Easter between the Western Church 
and the Eastern Church. The latter continues to use 
the Julian calendar dates as they were at the time of 
the Gregorian calendar reform. That is, the Eastern 
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Church recognizes the Gregorian calendar, but for 
certain feast days does not void the ten-day error 
that existed at the time of the calendar reform. 

Gregorian calendar. For the calendar reform, Pope 
Gregory XIII selected 2 the plan of Aloysius Lilius 



England and her colonies adopted 
the Gregorian calendar on Thursday, 
September 14, 1752. 



(1510-1576?),' who is also known as Luigi Lilio. 1 
This reform, known as the Gregorian calendar, was 
implemented on Friday, October 15, 1 582. 2 

Although use of the Gregorian calendar spread rap- 
idly among Roman Catholic countries, many cen- 
turies passed before it was generally used by non- 
Catholic countries. England and her colonies, in- 
cluding what is now the United States, adopted the 
calendar on Thursday, September 14, 1752. 3 Many 
other countries — notably China, Greece, and Rus- 
sia — did not adopt it until after the beginning of the 
20th century. In fact, Russia adopted the Gregorian 
calendar on two separate occasions, first in 19 18, 
about the same time as many other countries, and 
again on June 27, 1940. 4 Changes made in Russia in 
1929 to avoid the religious associations of the Gre- 
gorian calendar were unsuccessful, and it was reim- 
plemented in 1940, 

The reform that synchronized the calendar year with 
the tropical year required the removal of ten days 
from the calendar. As a result, Friday, October 15, 
1582, immediately followed Thursday, October 4, 
1582. (An alternate plan would have removed the 
ten excess days gradually by canceling leap days for 
40 years.) As before, every fourth year is a leap year, 
and, to maintain synchronization, centurial years 
that are evenly divisible by 400 are also leap years. 2 
Thus, for example, 1900 was a common year, the 
year 2000 will be a leap year, and the year 2 100 will 
start a series of common centurial years again; The 
result is an average calendar year of 365.2425 days, 
which closely approximates the tropical year. Despite 
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this close approximation, by the 44th century, the 
Gregorian calendar will again differ from the tropical 
year by one day. Because the tropical year consists 
of an irrational number of days, no calendar year 
with an integral number of days can exactly match 
the tropical year. Not only is there not an integral 




Discontinuities in the Gregorian 
calendar scheme cause most of the 
difficulties with date manipulation. 




number of days in a tropical year, but also the length 
of the day is not constant. That is, the length of the 
tropical year is also changing gradually. 

Algorithms for date processing 

Centurian date format. Discontinuities in the Gre- 
gorian calendar scheme cause most, if not all, ot the 
difficulties associated with date manipulation. In- 
stances of discontinuities are the following: 

. No calendar unit is evenly divisible by weeks. 
• The number of days per month vanes. 
. The number of days per year vanes. 
. The number of days per century vanes. 

These facts must be accounted for in calculating the 
number of days between two dates, calculating a date 
based on the addition or subtraction of days from 
another date, and calculating the day of the week for 
a date. A centurian date format (ddddd, represent- 
ing the day within a century) works well by giving 
continuous values within a century. Also, other date 
formats and day of week are readily calculable from 
this value. The centurian format is limited to a 
century and results in discrepancies when a century 
boundary is crossed. Consideration must be given to 
century years when making a leap year calculation^ 
The ddddd format will not span more than 273 
vears (or 179 years in a two-byte binary format). 
Also, a standard point of origin for the starting day 
must be defined. 

Lilian date format. The Lilian date format consists 
of seven positions for the number of days from the 



246 o** 6 



beginning of the Gregorian calendar. Day one ir 
Friday October 15, 1582, and the value is incre- 
mented by one for each subsequent day. Based on 
this format are services supporting 44 expenmental 
functions (or more if theahree dmy, mdy, and ymd 
experimental versions of the Gregorian format are 
counted) synthesized from eight mnemonics. 

Function-naming convention. Functions are named 
to promote easy recall and to suggest the activity to 
be performed. In the algorithm and expenmental 
pl/i program discussed in this paper, each function 
name is synthesized from two 3-letter mnemon.c 



parts. These mnemonic parts are 


• cll: 


compact Lilian date 


• day: 


day of the week 


• GRC: 


Gregorian date 


• jul: 


Julian date 


• ul: 


Lilian date 


• sgr: 


short Gregorian dale 


• sjl: 


short Julian date 


• val: 


validate a date 



The first part is a description of the target, and the 
second part is a description of the source, val (vali- 
dation) and day (day of week) can appear only in 
the target position of the function. 

Arguments presented to any of the conversion func- 
tions are always presented in the same order new 
date (target); old date (source); range date (control), 
when required; and Gregorian formal (specinen;s)J, 
when required. Table 1 illustrates the format for 
conversion arguments. In all instances, a return code 
is set. 

The format descriptions in Table 1 refer to the type 
of data-D for day, M for month, and Y for year 
as well as the number of positions (e.g., yy tor two 
year positions)-that the data occupy. The origin oi 
the term "Julian date" for the yyddd format is given 
in Reference 6. Nevertheless, dates ******** 
the Julian format conform to the Gregorian calendar 
and not to the Julian calendar. The Julian daw for 
Thursday, November 14, 1985, is 85318 (shortform) 
and 1985318 (extended form). 

Algorithms. The process of conversion between a 
Lilian format date and a Julian format date is no 
described. The algorithms are simpler to equate y 
choosing a virtual base date rather than : then*" ° 
After the calculations are made, any *screpan 
are resolved. In the following algorithms, tne 

BM SYSTEMS JOURNAL. VOL 25. NO 2. 1986 



ly one is 
is incre- 
Based on 
rimcnlal 
and ymd 
rmat are 
ics. 

£~e named 
activity to 
xrimental 

1 function 
nemonic 
as follows: 

I 
I 
I 

n y and the 

Ival (vali- 
only in 

Iiion func- 
rder. new 
: (control), 
3ecifier<s)], 
fcrmat for 
|turn code 

o the type 
for year, 
yy for two 

Ie origin of 
tat is given 
esentcd in 

I in calendar 
kn date for 
thort form) 



t 



between a 
ate is now 
ralculate by 

I e real one. 
screpanctes 

the num- 



Table 1 E 


xamples of conversion function arguments 




- 


Argument 


Description 





target=JULSJL (source. 1925) 

target=JUUGRG (source. DMY) 
target=ULGRG (source, YMD) 
target=CLLJUL (source) 
target=SGRGRG (source. YMD, MOY) 
CALL VAUUL (source) 
target=OAYSJL (source 1925) 



Conversion to a Julian (YYYYDDO) date froma short Jufan (YYDOO) date within the 
range 1925-2024 

Conversion to a Julian (YYYYDDO) date from a Gregorian (DDMMYYYY) date 

Conversion of a Lilian (packed format) date from a Gregorian (YYYYMMDD) date 

Conversion of a compact Lilian (binary format) date from a Julian date 

Conversion of a short Gregorian (YYMMDD) date from a Gregorian (MMDDYYYY) date 

Validation of a Julian date 

Day of week for a short Julian date 



bers in parentheses are results of calculations made 
on the previously given date, November 14, 1985. 

Extended Julian to Lilian. Given an extended Julian 
date (yyyyddd). compute the corresponding Lilian 
date. First, compute the number of days from virtual 
January I, 1501, to the start of the year being con- 
verted (1985318 Julian). 

• Subtract 1501 from the Julian year (484). 

• Multiply the difference by 365.25 (i.e., the average 
number of days per year) ( 1 76 78 1 .00). 

• Truncate the result. The leap day is kept only for 
full four years (176781). • 

Then compute the number of Julian calendar (not 
Julian format) days from October 15, 1582, to the 
date being converted. 

• Subtract 29872, i.e., the number of days between 
virtual January 1, 1501, and October 15, 1582 
(146909). 

• Add the Julian days (+318 = 147227). 

Next, make the Gregorian calendar adjustments to 
this value. 

• Subtract 1501 from the Julian year (484). 

• Divide the difference by 100. One leap year is 
usually skipped each century (4.84). 

• Truncate the result to obtain the number of whole 
leap days. Partial leap days do not exist (4). 

• Subtract the number of whole leap days from the 
number of Julian calendar days (147 223). 

Because one out of every four centuries keeps all of 
its leap years, use the virtual year 1201, which is the 



beginning of the four-century cycle that contains the 
year 1582, to compute the number of leap years up 
to the target date. 

• Subtract 1 201 from the Julian year. The first four- 
hundred-year cycle began with virtual year 1201 
and ended in the real 1600 (784). 

• Divide the difference by 400 because one century 
leap year per 400 years is kept ( 1 .96). 

• Truncate the result because partial leap days do 
not exist (1). 

• Add these leap days back into the adjusted Julian 
calendar days ( 1 47 224). 

~i final result is the number of Gregorian calendar 
days from the beginning of the Gregorian calendar 
(October 1 5, 1 582) to the date being converted. This 
result is the sought-for Lilian date. 

Lilian to extended Julian. The purpose of this ex- 
ample is to show the procedure for converting a 
Lilian date to an extended Julian date. First, create 
a virtual Lilian date, with a starting point of January 
1, 1201. Convert this result into a Julian calendar 
(not Julian format) date. Then convert the Julian 
calendar date to a Julian format date. The procedure 
is as follows (147224 Lilian): 

• Add 1 39 444 to the Lilian date. This is the number 
of days from virtual January 1, 1201 (the start of 
a 400-year cycle) to October 15, 1582. The result 
is a pseudo-Lilian date (286668). 

• Divide the pseudo-Lilian date. by 36524.25, the 
average number of days per century (7.85). 

• Truncate the result to obtain the number of cen- 
tury leap days (7). 
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o Add the number of century leap days to the 

pseudo-Lilian date (286675). 
. Divide the number of century leap days by 4 

. Truncate the result to obtain the number of four- 

. SSTSSt of four^ntury leap > days 
from the pseudo-Lilian date, because they are 
already included (286674). 

The result is the number of full Julian calendar days 
iomTanuary t, 1201, to the date being converted. 
We now convert this to an extended Julian format 

date. 

c Divide full Julian calendar days by 365.25. This 
usually gives one less than the year for the date 
being converted (784.87). u,—,.. 

. Sere is no remainder from the d.v,s.on, subtract 
one from the quotient; otherw.se, truncate the 
quotient to get the pseudo-Juhan pnor year (784)^ 

o Multiply the pseudo-Julian pnor year by 365.25 
TdeterLne die number of annual Julian calen- 
dar days prior to the year for the date bemg 
converted (286 356.00). t , 

. Se the number of annua. Jul an . calendar 
davs to eliminate partial leap days (286 356). 

o Set the numter of truncated annud Juhan 
calendar days from the full number of Juhan 
Sknda days to obtain the number of current 
SaTcalendar days in the year of the date being 

converted (318). ^ut^in 
o Addl201tothepseudo-Julianpnoryeartoobun 

ifreal Julian year, i.e., .200 ^ years pnor to 
1 200 Dlus one for the current year (+784 - 

its proper Julian format P^ on j 19 " 00 ^ • 
c Add the current Julian calendar days to the result 
to complete the Julian format date from the Uhan 
format date (1985318). 



Ease oJ ©wwefsieai 

Accommodating ml asm- End users usually enter 
tTagtefor *e year in a date »d understand the 
aTbSy that this represents. Therefore, even at the 
SnSfSe century, to avoid I adverse user reason 
programs must continue to mnction with ^ only t»o 
differ year. The inference of the year ^1997 from 
97 and 2003 from 03 must continue. For ^excep- 
tional case where the correct meaning could be 1897 
and!903, entry of all four digits may be requ.red. 
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The month-day-year and day-mondvyear form ats 
are ambiguous. Therefore, it might be advisable to 
continue presenting the date in its conventional U.S. 
format with a parenthetical explanation of the for- 
mat-such as (mm/dd/yy) =to avoid the ambiguity. 
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It is not necessary to change date 
formats in files, because it is possible 
to change the programs only. 
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However, it may be necessary to prov.de a conver- 
sion function that receives a definition of the implied 
century as a parameter. An excellent way to do this 
unambiguously is to specify a year as the desired 
starting point of a 100-year range. For example if ^ 
the starling year for the range is specified as 1925,/ f 
£tefwith 8 year digits of 25 through 99 would be! 
between 1925 and 1999/and dates wUh year dipts <? 
of 00 through 24 would fie between 2000 and 2024. J If 

Accommodating systems support. The conversion^ 
isolated files to new date formats presents a rather ^ 
trivial problem. In most cases, however, it is no 
possible to isolate the process. AH pro-ams tta 
access the modified data must be changed sunulta- 
Sy. In some large systems, literally thousands 
of programs may be involved. In these large ^systems, 
it may be prudent to avoid the cost and nsk of 
massive changes in a short period of tune. 

It is not necessary to change date formats in files, 
because it is possible to change the P^OS^S 
so that the implied century in a date is recogmzea 
Of course, in the vast majority of cases, that £ ex*** 
what does take place. Dates familiarly andnnphc^ 
exist within the 100-year range ^"^^J 9 ^ 
or 1901. Thus it is necessary merely to ™odn>u 
programs so that the 100-year range starts at a later 
SatTA beginning date set eighty years 
current systems date may be a reasonable conven 
tion. This is well within the range now in use. 

The significant feature of this approach* thateyery- 
tning need not be modified at once. The mod*** 
tionl may be made over a period of years dunog 
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normal program maintenance. Of course, as systems 
arc maintained or replaced, it would be practical to 
implement full information date formats. Where 
systems contain dates that span a range of more than 
100 years, the century must already have been car- 
ried. In the rare event that this is not true, immediate 
conversion is unavoidable. Fortunately, in most ap- 
plications, we can deal with centuries as exceptions 
rather than as a common problem. 

Computational considerations 

Storage. The two main considerations pertaining to 
storage are ( I ) the cost of storing large quantities of 
data; and (2) the computational cost of converting 
records within computer files to larger date-field 
sizes. When millions of dates are stored, as they are 
in most business systems, every additional byte re- 
quired to save a single date multiplies to millions of 
additional bytes of storage. The programming nec- 
essary to accommodate larger date-field sizes in rec- 
ords further complicates date conversion. 

Putting bounds on data-storage costs at reasonable 
levels and reducing conversion complications are 
both achievable. The allocation of additional space 
to record four positions for year, rather than the 
traditional two, is not the only possibility. Many 
systems currently store dates internally in packed 
Julian format, requiring three bytes of storage. In 
packed format, a Lilian date or an extended Julian 
date (yyyyddd) both require four bytes of storage. 
However, if a binary format were to be adopted, 
either form of date could be stored in the three bytes 
used at present. 

A more restrictive situation exists for systems in 
which dates are stored in two bytes instead of three. 
These systems use a binary format to record centu- 
rian or other forms of dates. In the near term for 
these systems, it may be necessary to continue storing 
dates in only two bytes. This cannot be accommo- 
dated with a Julian format However, it is possible 
to store a range of dates by taking advantage of the 
continuous characteristic of a Lilian date. 

Using the Lilian date system, any date in a selected 
range of 1 79 years may be stored as follows. Assume 
that the selected range is January 1, 1901, through 
December 3 1 , 2079. Find the Lilian value of Decem- 
ber 31, 1900. Subtract this value from the Lilian 
value of the date to be stored. Convert the result to 
a 16-bit (two-byte) binary value and store the result. 
Reverse the process to restore the two-byte date to 



Lilian format. Continuing to store dates in two bytes 
should be considered only where the programming 
cost of increasing record sizes in an existing system 
is prohibitive. The decreasing cost of storage makes 
the use of the full Lilian or Julian format a practical 
possibility when an application is being modified. 

In the experiments on which this paper is based, the 
three-byte Lilian format for data storage has been 




The continuous nature of the Lilian 
date accommodates the types of 
processing that normally take place. 




found to be preferable. Internally, in computer use, 
the continuous nature of the Lilian date accommo- 
dates the types of processing that normally take place 
within a program. In addition, for all three storage 
sizes, a consistent format (i.e., the all-Lilian format 
or the quasi-Lilian format) is maintained. 

Flexibility. In our experiments, the ibm System 360/ 
?"*0 assembly language was used for coding the date 
functions. However, the method is easily adaptable 
to other programming languages such as COBOL, 
pl/i, and rpg. The experimental functions were also 
made re-entrant for flexibility within on-line envi- 
ronments. 

Validity. Ideally, the validation of a date is necessary 
only at the point of its manual entry into a system. 
Experience teaches us that it is not unusual for an 
interfacing system to provide invalid dates. There- 
fore, all dates passed to conversion functions must 
be validated. When an invalid date is encountered 
by the experimental system, a null value is returned 
to the invoking program and a return code is set to 
indicate the nature of the invalid condition. 

Efficiency. Date conversions are used heavily within 
certain applications. Because of the impact on a 
single system or an installation, efficiency must be 
inherent in date-conversion programs. Storage re- 
quirements for external display and internal calcu- 
lations by computer programs are expected to mo 
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tivate a high volume of conversions. Widely used 
programs in high-volume environments must per- 
form well and not consume excessive amounts of 
storage. A date-conversion program that is good in 
all other ways will not be widely used if it is an 
operational bottleneck. 

For the program discussed in this paper, written in 
System 360/370 assembly language and imple- 



Programs that embody all these qualities have been 
written and tested experimentally. The application 
as written requires less than 4K bytes of storage and 
has an average execution path of fewer than 100 
machine language instructions. Re-en trancy and the 
possibility of multilanguage implementation indicate 
excellent flexibility. This approach presents a prac- 
tical method of processing dates that is compatible 
with any dating format standard. 



Experimental results indicated good 
efficiency. 




mented as a set of pl/i functions, the experimental 
results indicated good efficiency. The longest execu- 
tion paths, including pl/i prologue, validation, con- 
version, and pl/i epilogue, are a little more than one 
hundred machine-language instructions. Although 
the functions appear to the invoking pl/i program 
to 'se separate programs, they are ail actually pro- 
vided within a single program that requires less than 
4K bytes of storage. 

Concluding remarks 

Programmers require date-processing functions that 
effectively handle applications for both the present 
and the future. For the present, it is sufficient to 
validate source dates, to convert from one traditional 
date format to another, and to perform addition or 
subtraction operations involving dates. For the fu- 
ture additional functions are required that support 
processing restricted only by the limitations of the 
Gregorian calendar. These functions must be fully 
compatible with existing date-format and record-size 
restrictions. Massive conversion efforts should not 
be required to process and store dates outside the 
twentieth century. Also, end users should be able to 
continue to use existing two-digit date formats when 
interacting with computer systems. In all cases the 
programs that provide these services must be reliable, 
efficient in the use of both processor and storage, 
and flexible in application. 
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